After many software products are released to market (RTM), software developers periodically release additional product content for the software product. That is, when a software product deploys updated product content, an administrator (user) of an operating system may need to revert to a previous state of the software product due to work requirements, consulting engagements or bugs in the product content. The administrator often needs to be aware of all product content as well as when such product content was installed to correctly, and safely, remove undesired (i.e., problematic) product content during software product updating procedures. Often, the administrator removes product content or adds it, in a wrong sequence thereby causing software product instability and/or inoperability. This adversely impacts usability, and supportability of the software product; (e.g., a software support group has to ask the user to reinstall the entire operating system and/or software product to continue using the software product.)
Typically, to install product content on a computing device, a user needs to know several factors including: an initial configuration state of the software product; all previously-installed product content; requisite product content to achieve the desired final configuration state of the software product; the order of applying the product content during the updating process; and the remaining product content after modifying the software product.
Unfortunately, previously-installed product content is often located at a source external to the user's computing device, requiring the administrator to manually access and transfer such previously-installed product to the computing device. This is a time consuming and tedious process. Furthermore, the administrator needs to install the updated product content in a specific order to achieve a stable, desired final configuration state of the software product. Such an updating process requires the administrator to understand the above-listed factors and meticulously install the product content in a piece-meal manner. For single computers, such a product content updating process is complex. For multiple computing devices residing on an enterprise network, for example, the administrator needs to manage large quantities of product content, which may not be up-to-date for each computing device. This risk complicates the process of updating only selected computing devices on the enterprise network and jeopardizes the desired final configuration state of the software product residing on the enterprise network.
In a non-limiting exemplary scenario, as product content updates grow over time, most software products will build service packs which “roll up” product content into larger product content releases. Often such service packs cannot be uninstalled or, if they are, such a removal process cancels previously applied hotfixes and reverts the software product configuration state back to the previous full service pack (i.e., full software product release). Such an undesirable reversion process removes more than targeted product content updates and, thus fails to update a specific hotfix or feature pack within the larger service pack release.
That is, a product moving from an initial RTM configuration state to a Service Pack 1 (SP1) configuration state will target SP1 product content against delta updates released between the RTM and SP1 dates. This scenario occurs when the software product finds a security issue or other bug that needs to be fixed in product content released before and/or after SP1. For brevity, the present non-limiting exemplary scenario impacts only one file. The product content before SP1 does not have additional fixes that occurred when SP1 was released. Shipping such pre-SP1 product content will break functionality of the software product, thereby requiring shipment of two separate versions of the product content with each hotfix. The problem occurs when the administrator of the computing device updates the software product up to the SP1 release date. However, the initial SP1 product content was not aware of the hotfix and, therefore, does not update the hotfix during the updating process.
One conventional solution is to author the SP1 product content and render obsolete all delta updates that occurred between the RTM and SP1 dates. Another solution is to have a product content deployment engine copy all product content, to be removed or updated, to a temporary location thereby allowing a future rollback of such product content. Both solutions are time consuming and inefficient.
In another non-limiting exemplary scenario, the administrator may apply previously released product content patches out of sequence. If a selected delta patch is not using a subsystem (i.e., deployment engine) which is aware of applicability rules, such a delta patch may be erroneously applied in a manner that degrades software product functionality. Further, even if the delta patch is aware of applicability rules, the administrator may have to search through release notes, knowledge base articles or other product notification channels to find all applicable delta released updates to the product content. Often this inhibits the ability to discover and apply all requisite patches (updates) to the software product.